Datenintensive Anwendungen designen by Martin Kleppmann

Autor:Martin Kleppmann
Die sprache: deu
Format: epub
Herausgeber: dpunkt
veröffentlicht: 2018-05-15T00:00:00+00:00

Systemmodell und Realität

Viele Algorithmen sind entwickelt worden, um die Probleme verteilter Systeme zu lösen – zum Beispiel untersuchen wir in Kapitel 9 Lösungen für das Konsensproblem. Um nützlich zu sein, müssen diese Algorithmen verschiedene Fehler verteilter Systeme tolerieren, die wir in diesem Kapitel besprochen haben.

Algorithmen müssen so geschrieben werden, dass sie nicht zu stark von den Details der zugrunde liegenden Hardware- und Softwarekonfiguration abhängig sind. Dies wiederum setzt voraus, dass wir die Fehlerarten, die wir in einem System erwarten, irgendwie formalisieren. Dazu definieren wir ein Systemmodell, das als Abstraktion beschreibt, wovon ein Algorithmus ausgehen kann.

In Bezug auf zeitliche Annahmen sind drei Systemmodelle gebräuchlich:

Synchrones Modell

Das synchrone Modell geht von einer begrenzten Netzwerkverzögerung, begrenzten Prozesspausen und begrenzten Uhrenfehlern aus. Das bedeutet weder exakt synchronisierte Uhren noch null Netzwerkverzögerung, sondern lediglich, dass Sie wissen, dass Netzwerkverzögerung, Pausen und Uhrendrift niemals eine feste obere Grenze überschreiten werden [ 88 ]. Das synchrone Modell ist kein realistisches Modell der meisten praktischen Systeme, weil (wie in diesem Kapitel erläutert) unbegrenzte Verzögerungen und Pausen auftreten.

Teilsynchrones Modell

Partielle Synchronität bedeutet, dass sich ein System die meiste Zeit wie ein synchrones System verhält, manchmal aber die Grenzen für Netzwerkverzögerung, Prozesspausen und Uhrendrift überschreitet [ 88 ]. Dies ist ein realistisches Modell vieler Systeme: Netzwerke und Prozesse verhalten sich ordnungsgemäß – andernfalls könnten wir nie etwas erreichen –, doch wir müssen damit rechnen, dass zeitliche Annahmen gelegentlich zerschlagen werden. In diesem Fall können Netzwerkverzögerungen, Pausen und Uhrendrift beliebig groß werden.

Asynchrones Modell

In diesem Modell darf ein Algorithmus keine zeitlichen Annahmen treffen – tatsächlich besitzt er nicht einmal eine Uhr (und kann daher auch keine Timeouts verwenden). Einige Algorithmen lassen sich für das asynchrone Modell entwerfen, doch es ist sehr restriktiv.

Neben Timing-Problemen müssen wir auch Knotenausfälle berücksichtigen. Die drei häufigsten Systemmodelle für Knoten sind:

Crash-Stopp-Fehler

Im Crash-Stopp-Modell kann ein Algorithmus davon ausgehen, dass ein Knoten nur auf eine Art und Weise ausfallen kann, nämlich durch Absturz. Das heißt, dass der Knoten plötzlich nicht mehr reagiert und danach für immer verschwunden ist – er kommt nie mehr zurück.

Crash-Wiederherstellungs-Fehler

Wir gehen davon aus, dass Knoten jederzeit abstürzen und nach einer unbekannten Zeit vielleicht wieder reagieren können. Das Crash-Wiederherstellungs-Modell nimmt an, dass Knoten einen stabilen Speicher (d.h. nichtflüchtigen Plattenspeicher) besitzen, der gegen Abstürze gesichert ist, während der Arbeitsspeicherzustand als verloren angenommen wird.

Byzantinische (willkürliche) Fehler

Knoten können absolut alles tun, unter anderem auch versuchen, andere Knoten auszutricksen und zu täuschen, wie im letzten Abschnitt beschrieben.

Für die Modellierung realer Systeme ist das teilsynchrone Modell mit Crash-Wiederherstellungs-Fehlern im Allgemeinen das sinnvollste Modell. Doch wie kommen verteilte Algorithmen mit diesem Modell klar?

Download

Haftungsausschluss:
Diese Site speichert keine Dateien auf ihrem Server. Wir indizieren und verlinken nur                                                  Inhalte von anderen Websites zur Verfügung gestellt. Wenden Sie sich an die Inhaltsanbieter, um etwaige urheberrechtlich geschützte Inhalte zu entfernen, und senden Sie uns eine E-Mail. Wir werden die entsprechenden Links oder Inhalte umgehend entfernen.